IRIX Base Documentation 2001 May/SGI IRIX Base Documentation 2001 May.iso/usr/share/catman/p_man/cat5/signal.z/signal

Text File | 2001-04-17 | 28.0 KB | 397 lines

SSSSIIIIGGGGNNNNAAAALLLL((((5555))))                                                            SSSSIIIIGGGGNNNNAAAALLLL((((5555))))



NNNNAAAAMMMMEEEE
     _ssss_iiii_gggg_nnnn_aaaa_llll - base signals

SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
     _####_iiii_nnnn_cccc_llll_uuuu_dddd_eeee _<<<<_ssss_iiii_gggg_nnnn_aaaa_llll_...._hhhh_>>>>

DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
     A signal is an asynchronous notification of an event.  A signal is said
     to be generated for (or sent to) a process or a thread when the event
     associated with that signal first occurs.  Examples of such events
     include hardware faults, timer expiration and terminal activity, as well
     as the invocation of the _kkkk_iiii_llll_llll(2), _ssss_iiii_gggg_qqqq_uuuu_eeee_uuuu_eeee(3) or _ssss_iiii_gggg_ssss_eeee_nnnn_dddd(2) system calls.
     In some circumstances, the same event generates signals for multiple
     processes.  A process may request a detailed notification of the source
     of the signal and the reason why it was generated [see _ssss_iiii_gggg_iiii_nnnn_ffff_oooo(5)].

     At the time of generation, the system will determine whether the signal
     is directed at a process or a specific thread within that process.
     Signals that are naturally associated with a particular thread, such as
     hardware faults, are directed to the appropriate thread.  This is usually
     due to the signal being generated during the execution of the thread and,
     moreover, in the context of executing that thread.  Signals that are sent
     to a process tend to be those that are generated asynchronously with
     respect to the execution of the process.  Signals generated by the _k_i_l_l
     interface or sent as a result of a tty interrupt are examples of signals
     directed at a process.

     Each process may specify a system action to be taken in response to each
     signal sent to it, called the signal's disposition.  For multithreaded
     processes, the disposition is shared by all threads in the process.  The
     set of system signal actions for a process is initialized from that of
     its parent.  Once an action is installed for a specific signal, it
     usually remains installed until another disposition is explicitly
     requested by a call to either _ssss_iiii_gggg_aaaa_cccc_tttt_iiii_oooo_nnnn(2), _ssss_iiii_gggg_nnnn_aaaa_llll(2), _ssss_iiii_gggg_nnnn_aaaa_llll(3B),
     _ssss_iiii_gggg_vvvv_eeee_cccc(3B) or _ssss_iiii_gggg_ssss_eeee_tttt(2), or until the process execs [see _ssss_iiii_gggg_aaaa_cccc_tttt_iiii_oooo_nnnn(2) and
     _ssss_iiii_gggg_nnnn_aaaa_llll(2)].  When a process execs, all signals whose disposition has been
     set to catch the signal will be set to _SSSS_IIII_GGGG______DDDD_FFFF_LLLL.  Alternatively, a process
     may request that the system automatically reset the disposition of a
     signal to _SSSS_IIII_GGGG______DDDD_FFFF_LLLL after it has been caught [see _ssss_iiii_gggg_aaaa_cccc_tttt_iiii_oooo_nnnn(2) and
     _ssss_iiii_gggg_nnnn_aaaa_llll(2)].

     A signal is said to be delivered to a process or thread when the
     appropriate action for the signal is taken.  During the time between the
     generation of a signal and its delivery, the signal is said to be pending
     [see _ssss_iiii_gggg_pppp_eeee_nnnn_dddd_iiii_nnnn_gggg(2)].  Ordinarily, this interval cannot be detected by an
     application.  However, a signal can be blocked from delivery to a thread
     [see _ssss_iiii_gggg_hhhh_oooo_llll_dddd(2), _ssss_iiii_gggg_bbbb_llll_oooo_cccc_kkkk(3) and _ssss_iiii_gggg_pppp_rrrr_oooo_cccc_mmmm_aaaa_ssss_kkkk(2)].  If the action
     associated with a blocked signal is anything other than to ignore the
     signal, and if that signal is generated for the process or thread, the
     signal remains pending until either it is unblocked or the signal's
     disposition requests that the signal be ignored.  Signals generated for
     the process shall be delivered to exactly one of the threads within the



                                                                        PPPPaaaaggggeeee 1111






SSSSIIIIGGGGNNNNAAAALLLL((((5555))))                                                            SSSSIIIIGGGGNNNNAAAALLLL((((5555))))



     process.  The thread must either be executing the _s_i_g_w_a_i_t function
     selecting that signal or it must not be blocking delivery of the signal.
     If there are no threads in a call to a _s_i_g_w_a_i_t function selecting that
     signal, and if all threads within the process block delivery of the
     signal, the signal shall remain pending of the process until either a
     thread calls a _s_i_g_w_a_i_t function selecting that signal, a thread unblocks
     delivery of that signal, or the action associated with the signal is set
     to ignore the signal.  If the signal disposition of a blocked signal
     requests that the signal be ignored, and if that signal is generated for
     the process or thread, the signal is discarded immediately upon
     generation.

     On IRIX, a pending signal is usually delivered when a thread returns from
     the kernel. This happens at the end of a system call or at the end of a
     hardware interrupt. Since the scheduling clock interrupt occurs at a
     regular 10 msec interval, this means that the latency between the
     generation of a signal and its delivery can never be more than 10 msec.
     For real-time application(defined as process with high band non-degrading
     priority), a generation of a signal always force an immediate signal
     delivery.

     Each thread has a signal mask that defines the set of signals currently
     blocked from delivery to it [see _ssss_iiii_gggg_pppp_rrrr_oooo_cccc_mmmm_aaaa_ssss_kkkk(2) or _pppp_tttt_hhhh_rrrr_eeee_aaaa_dddd______ssss_iiii_gggg_mmmm_aaaa_ssss_kkkk(3P)].
     The signal mask for a thread is initialized from the thread that created
     it.

     The determination of which action is taken in response to a signal is
     made at the time the signal is delivered, allowing for any changes since
     the time of generation.  This determination is independent of the means
     by which the signal was originally generated.

     The signals currently defined in _ssss_iiii_gggg_nnnn_aaaa_llll_...._hhhh are as follows:

    Name         Value   Default   Event
    __________________________________________________________________________
    _SSSS_IIII_GGGG_HHHH_UUUU_PPPP       1       Exit      Hangup [see _tttt_eeee_rrrr_mmmm_iiii_oooo(7)]
    _SSSS_IIII_GGGG_IIII_NNNN_TTTT       2       Exit      Interrupt [see _tttt_eeee_rrrr_mmmm_iiii_oooo(7)]
    _SSSS_IIII_GGGG_QQQQ_UUUU_IIII_TTTT      3       Core      Quit [see _tttt_eeee_rrrr_mmmm_iiii_oooo(7)]
    _SSSS_IIII_GGGG_IIII_LLLL_LLLL       4       Core      Illegal Instruction
    _SSSS_IIII_GGGG_TTTT_RRRR_AAAA_PPPP      5       Core      Trace, Breakpoint, Range Error
                                   Divide by Zero, or Overflow Trap
    _SSSS_IIII_GGGG_AAAA_BBBB_RRRR_TTTT      6       Core      Abort
    _SSSS_IIII_GGGG_EEEE_MMMM_TTTT       7       Core      Emulation Trap
    _SSSS_IIII_GGGG_FFFF_PPPP_EEEE       8       Core      Arithmetic Exception
    _SSSS_IIII_GGGG_KKKK_IIII_LLLL_LLLL      9       Exit      Killed
    _SSSS_IIII_GGGG_BBBB_UUUU_SSSS       10      Core      Bus Error
    _SSSS_IIII_GGGG_SSSS_EEEE_GGGG_VVVV      11      Core      Segmentation Fault
    _SSSS_IIII_GGGG_SSSS_YYYY_SSSS       12      Core      Bad System Call
    _SSSS_IIII_GGGG_PPPP_IIII_PPPP_EEEE      13      Exit      Broken Pipe
    _SSSS_IIII_GGGG_AAAA_LLLL_RRRR_MMMM      14      Exit      Alarm Clock





                                                                        PPPPaaaaggggeeee 2222






SSSSIIIIGGGGNNNNAAAALLLL((((5555))))                                                            SSSSIIIIGGGGNNNNAAAALLLL((((5555))))



    _SSSS_IIII_GGGG_TTTT_EEEE_RRRR_MMMM      15      Exit      Terminated
    _SSSS_IIII_GGGG_UUUU_SSSS_RRRR_1111      16      Exit      User Signal 1
    _SSSS_IIII_GGGG_UUUU_SSSS_RRRR_2222      17      Exit      User Signal 2
    _SSSS_IIII_GGGG_CCCC_HHHH_LLLL_DDDD      18      Ignore    Child Status Changed
    _SSSS_IIII_GGGG_PPPP_WWWW_RRRR       19      Ignore    Power Fail/Restart
    _SSSS_IIII_GGGG_WWWW_IIII_NNNN_CCCC_HHHH     20      Ignore    Window Size Change
    _SSSS_IIII_GGGG_UUUU_RRRR_GGGG       21      Ignore    Urgent Socket Condition
    _SSSS_IIII_GGGG_PPPP_OOOO_LLLL_LLLL      22      Exit      Pollable Event [see _ssss_tttt_rrrr_eeee_aaaa_mmmm_iiii_oooo(7)]
    _SSSS_IIII_GGGG_IIII_OOOO        22      Exit      input/output possible signal
    _SSSS_IIII_GGGG_SSSS_TTTT_OOOO_PPPP      23      Stop      Stopped (signal)
    _SSSS_IIII_GGGG_TTTT_SSSS_TTTT_PPPP      24      Stop      Stopped (user) [see _tttt_eeee_rrrr_mmmm_iiii_oooo(7)]
    _SSSS_IIII_GGGG_CCCC_OOOO_NNNN_TTTT      25      Ignore    Continued
    _SSSS_IIII_GGGG_TTTT_TTTT_IIII_NNNN      26      Stop      Stopped (tty input) [see _tttt_eeee_rrrr_mmmm_iiii_oooo(7)]
    _SSSS_IIII_GGGG_TTTT_TTTT_OOOO_UUUU      27      Stop      Stopped (tty output) [see _tttt_eeee_rrrr_mmmm_iiii_oooo(7)]
    _SSSS_IIII_GGGG_VVVV_TTTT_AAAA_LLLL_RRRR_MMMM    28      Exit      Virtual Timer Expired
    _SSSS_IIII_GGGG_PPPP_RRRR_OOOO_FFFF      29      Exit      Profiling Timer Expired
    _SSSS_IIII_GGGG_XXXX_CCCC_PPPP_UUUU      30      Core      CPU time limit exceeded [see _gggg_eeee_tttt_rrrr_llll_iiii_mmmm_iiii_tttt(2)]
    _SSSS_IIII_GGGG_XXXX_FFFF_SSSS_ZZZZ      31      Core      File size limit exceeded [see _gggg_eeee_tttt_rrrr_llll_iiii_mmmm_iiii_tttt(2)]
    _SSSS_IIII_GGGG_CCCC_KKKK_PPPP_TTTT      33      Ignore    Checkpoint warning [see _cccc_pppp_rrrr(1)]
    _SSSS_IIII_GGGG_RRRR_EEEE_SSSS_TTTT_AAAA_RRRR_TTTT   34      Ignore    Restart warning [see _cccc_pppp_rrrr(1)]
    _SSSS_IIII_GGGG_RRRR_TTTT_MMMM_IIII_NNNN     49      Exit      POSIX 1003.1b SIGRTMIN
    _SSSS_IIII_GGGG_RRRR_TTTT_MMMM_AAAA_XXXX     64      Exit      POSIX 1003.1b SIGRTMAX

     IRIX supports all signal numbers between 0 and 64. All signals between 0
     and 32 are currently used. POSIX 1003.1b reserves all signals between
     _SSSS_IIII_GGGG_RRRR_TTTT_MMMM_IIII_NNNN and _SSSS_IIII_GGGG_RRRR_TTTT_MMMM_AAAA_XXXX for real-time applications.  Even though the kernel
     does not use any signals between 35 and 64, signal number between 35 and
     49 are not guaranteed to be available to user programs in future
     releases. Further more, the default behavior for signals between 35 and
     49 is to exit.

     No signals beyond 32 are applicable to the Berkeley signal functions
     because these functions use a fixed 32 bits signal mask as part the
     programming interface.

     Higher priority signals are delivered first when multiple unblocked
     signals are pending in order to prioritize event notifications. On the
     other hand, a lower priority signal can not preempt a higher priority
     signal handler.

     All signals between 0 and 32 are of equal priority but all are at higher
     priority than signals between _SSSS_IIII_GGGG_RRRR_TTTT_MMMM_IIII_NNNN and _SSSS_IIII_GGGG_RRRR_TTTT_MMMM_AAAA_XXXX.  Within the range of
     _SSSS_IIII_GGGG_RRRR_TTTT_MMMM_IIII_NNNN to _SSSS_IIII_GGGG_RRRR_TTTT_MMMM_AAAA_XXXX, the lower the signal number the higher the priority
     of that signal.

     Using the _ssss_iiii_gggg_nnnn_aaaa_llll(2), _ssss_iiii_gggg_nnnn_aaaa_llll(3B), _ssss_iiii_gggg_ssss_eeee_tttt(2), _ssss_iiii_gggg_vvvv_eeee_cccc(3B)  or _ssss_iiii_gggg_aaaa_cccc_tttt_iiii_oooo_nnnn(2)
     system call, a process may specify one of three dispositions for a
     signal:  take the default action for the signal, ignore the signal, or
     catch the signal.






                                                                        PPPPaaaaggggeeee 3333






SSSSIIIIGGGGNNNNAAAALLLL((((5555))))                                                            SSSSIIIIGGGGNNNNAAAALLLL((((5555))))



   DDDDeeeeffffaaaauuuulllltttt AAAAccccttttiiiioooonnnn:::: _SSSS_IIII_GGGG______DDDD_FFFF_LLLL
     A disposition of _SSSS_IIII_GGGG______DDDD_FFFF_LLLL specifies the default action.  The default
     action for each signal is listed in the table above and is selected from
     the following:

     Exit    When it gets the signal, the receiving process is to be
             abnormally terminated with all the consequences outlined in
             ______eeee_xxxx_iiii_tttt(2).

     Core    When it gets the signal, the receiving process is to be
             abnormally terminated with all the consequences outlined in
             ______eeee_xxxx_iiii_tttt(2).  In addition, a ``core image'' of the process is
             constructed in the current working directory.

     Stop    When it gets the signal, the receiving process is to stop.

     Ignore  When it gets the signal, the receiving process is to ignore it.
             This is identical to setting the disposition to _SSSS_IIII_GGGG______IIII_GGGG_NNNN.

   IIIIggggnnnnoooorrrreeee SSSSiiiiggggnnnnaaaallll:::: _SSSS_IIII_GGGG______IIII_GGGG_NNNN
     A disposition of _SSSS_IIII_GGGG______IIII_GGGG_NNNN specifies that the signal is to be ignored.

   CCCCaaaattttcccchhhh SSSSiiiiggggnnnnaaaallll:::: _f_u_n_c_t_i_o_n _a_d_d_r_e_s_s
     A disposition that is a function address specifies that, when it gets the
     signal, the receiving thread is to execute the signal handler at the
     specified address. Under IRIX, there are two ways a signal handler can be
     delivered.  If _SSSS_AAAA______SSSS_IIII_GGGG_IIII_NNNN_FFFF_OOOO is set in the field _s_a__f_l_a_g_s of the _s_i_g_a_c_t_i_o_n__t
     structure during a previous call to the _ssss_iiii_gggg_aaaa_cccc_tttt_iiii_oooo_nnnn(2) function for the
     signal being delivered, the signal handler will be invoked as follows:

          hhhhaaaannnnddddlllleeeerrrr ((((iiiinnnntttt ssssiiiigggg,,,, ssssiiiiggggiiiinnnnffffoooo____tttt ****ssssiiiipppp,,,, uuuuccccoooonnnntttteeeexxxxtttt____tttt ****uuuupppp))));;;;

     otherwise the signal handler will be invoked as follows:

          hhhhaaaannnnddddlllleeeerrrr ((((iiiinnnntttt ssssiiiigggg,,,, iiiinnnntttt ccccooooddddeeee,,,, ssssttttrrrruuuucccctttt ssssiiiiggggccccoooonnnntttteeeexxxxtttt ****sssscccc))));;;;

     Where _h_a_n_d_l_e_r is the specified signal handler function-name.  Due to
     historic implementations, signal handlers have been defined with zero,
     one, or three parameters.  To avoid source incompatibilities, in _CCCC, the
     prototype for the signal handler has intentionally been left empty.  _CCCC_++++_++++
     requires a prototype, so a compromise must be made.  _CCCC_++++_++++ user's should
     cast their handler to the type _SSSS_IIII_GGGG______PPPP_FFFF in order to be portable.

     Please see _ssss_iiii_gggg_iiii_nnnn_ffff_oooo(5) and _uuuu_cccc_oooo_nnnn_tttt_eeee_xxxx_tttt(5) for more details on the meanings of
     the passed in parameters of the first form.  The second form is the
     default system behavior.

     In the second form, _c_o_d_e is valid only in the following cases:

     Condition                        Signal      Code

     User breakpoint                  SIGTRAP     BRK_USERBP



                                                                        PPPPaaaaggggeeee 4444






SSSSIIIIGGGGNNNNAAAALLLL((((5555))))                                                            SSSSIIIIGGGGNNNNAAAALLLL((((5555))))



     User breakpoint                  SIGTRAP     BRK_SSTEPBP
     Integer overflow                 SIGFPE      BRK_OVERFLOW
     Divide by zero                   SIGFPE      BRK_DIVZERO
     Multiply overflow                SIGFPE      BRK_MULOVF
     Invalid virtual address          SIGSEGV     EFAULT
     Read-only address                SIGSEGV     EACCES
     Read beyond mapped object        SIGSEGV     ENXIO
     Autogrow for file failed         SIGSEGV     ENOSPC
     Automatic memory lock failed     SIGSEGV     ENOMEM

     Integer divide by zero, multiply overflow, integer overflow, and range
     errors are special cases. If the binary is not an IRIX 4 binary and a
     signal handler is installed for SIGFPE then the SIGFPE handler is called,
     otherwise SIGTRAP is called. This behavior is included to keep older IRIX
     4 and IRIX 5 binaries working, however the correct way to code a handler
     is to use SIGFPE.

     The third argument _s_c of the second form is a pointer to a _s_t_r_u_c_t
     _s_i_g_c_o_n_t_e_x_t (defined in <_s_y_s/_s_i_g_n_a_l._h>) that contains the processor
     context at the time of the signal.

     When the signal handler returns, the receiving thread resumes execution
     at the point it was interrupted, unless the signal handler makes other
     arrangements.  If an invalid function address is specified, results are
     undefined.

     If the disposition has been set with the _ssss_iiii_gggg_nnnn_aaaa_llll(3B), _ssss_iiii_gggg_ssss_eeee_tttt(2),
     _ssss_iiii_gggg_vvvv_eeee_cccc(3B) or _ssss_iiii_gggg_aaaa_cccc_tttt_iiii_oooo_nnnn(2) function, the signal is automatically blocked
     by the system while the signal catcher is executing.  If a _llll_oooo_nnnn_gggg_jjjj_mmmm_pppp [see
     _ssss_eeee_tttt_jjjj_mmmm_pppp(3C)] is used to leave the signal catcher, then the signal must be
     explicitly unblocked by the user [see _ssss_iiii_gggg_rrrr_eeee_llll_ssss_eeee(2), _ssss_iiii_gggg_pppp_rrrr_oooo_cccc_mmmm_aaaa_ssss_kkkk(2), and
     _pppp_tttt_hhhh_rrrr_eeee_aaaa_dddd______ssss_iiii_gggg_mmmm_aaaa_ssss_kkkk(3P)].

     If execution of the signal handler interrupts a blocked system call, the
     handler is executed and the interrupted system call returns a -1 to the
     calling thread with _eeee_rrrr_rrrr_nnnn_oooo set to _EEEE_IIII_NNNN_TTTT_RRRR.  However, if the _SSSS_AAAA______RRRR_EEEE_SSSS_TTTT_AAAA_RRRR_TTTT flag
     is set the system call will be transparently restarted.

NNNNOOOOTTTTEEEESSSS
     The dispositions of the _SSSS_IIII_GGGG_KKKK_IIII_LLLL_LLLL and _SSSS_IIII_GGGG_SSSS_TTTT_OOOO_PPPP signals cannot be altered
     from their default values.  The system generates an error if this is
     attempted.

     The _SSSS_IIII_GGGG_KKKK_IIII_LLLL_LLLL and _SSSS_IIII_GGGG_SSSS_TTTT_OOOO_PPPP signals cannot be blocked.  The system silently
     enforces this restriction.

     Whenever a process receives a _SSSS_IIII_GGGG_SSSS_TTTT_OOOO_PPPP, _SSSS_IIII_GGGG_TTTT_SSSS_TTTT_PPPP, _SSSS_IIII_GGGG_TTTT_TTTT_IIII_NNNN, or _SSSS_IIII_GGGG_TTTT_TTTT_OOOO_UUUU
     signal, regardless of its disposition, any pending _SSSS_IIII_GGGG_CCCC_OOOO_NNNN_TTTT signal are
     discarded. Further more, the process will not act upon any delivered
     signals other than _SSSS_IIII_GGGG_KKKK_IIII_LLLL_LLLL until a _SSSS_IIII_GGGG_CCCC_OOOO_NNNN_TTTT is received.





                                                                        PPPPaaaaggggeeee 5555






SSSSIIIIGGGGNNNNAAAALLLL((((5555))))                                                            SSSSIIIIGGGGNNNNAAAALLLL((((5555))))



     Whenever a process receives a _SSSS_IIII_GGGG_CCCC_OOOO_NNNN_TTTT signal, regardless of its
     disposition, any pending _SSSS_IIII_GGGG_SSSS_TTTT_OOOO_PPPP, _SSSS_IIII_GGGG_TTTT_SSSS_TTTT_PPPP, _SSSS_IIII_GGGG_TTTT_TTTT_IIII_NNNN, and _SSSS_IIII_GGGG_TTTT_TTTT_OOOO_UUUU signals
     is discarded.  In addition, if the process was stopped, it is continued.

     When a signal is delivered to a thread, if the action of that signal
     specifies termination, stop, or continue, all the threads in the process
     shall be terminated, stopped, or continued, respectively.

     Processes which are blocked via a _b_l_o_c_k_p_r_o_c system call will unblock if
     they receive a signal which is fatal (i.e., a non-job-control signal
     which the are NOT catching), but will still be stopped if the job of
     which they are a part is stopped.  Only upon restart will they die.  Any
     non-fatal signals received by a blocked process will NOT cause the
     process to be unblocked (an _u_n_b_l_o_c_k_p_r_o_c(2) or _u_n_b_l_o_c_k_p_r_o_c_a_l_l(2) system
     call is necessary).

     _SSSS_IIII_GGGG_PPPP_OOOO_LLLL_LLLL is issued when a file descriptor corresponding to a STREAMS [see
     _iiii_nnnn_tttt_rrrr_oooo(2)] file has a ``selectable'' event pending.  A process must
     specifically request that this signal be sent using the _IIII______SSSS_EEEE_TTTT_SSSS_IIII_GGGG _iiii_oooo_cccc_tttt_llll
     call.  Otherwise, the process will never receive _SSSS_IIII_GGGG_PPPP_OOOO_LLLL_LLLL.

     If the disposition of the _SSSS_IIII_GGGG_CCCC_HHHH_LLLL_DDDD signal has been set with _ssss_iiii_gggg_nnnn_aaaa_llll, _ssss_iiii_gggg_vvvv_eeee_cccc
     or _ssss_iiii_gggg_ssss_eeee_tttt, or with _ssss_iiii_gggg_aaaa_cccc_tttt_iiii_oooo_nnnn and the _SSSS_AAAA______NNNN_OOOO_CCCC_LLLL_DDDD_SSSS_TTTT_OOOO_PPPP flag has been
     specified, it will only be sent to the calling process when its children
     exit; otherwise, it will also be sent when the calling process's children
     are stopped or continued due to job control.

     The name _SSSS_IIII_GGGG_CCCC_LLLL_DDDD is also defined in this header file and identifies the
     same signal as _SSSS_IIII_GGGG_CCCC_HHHH_LLLL_DDDD. _SSSS_IIII_GGGG_CCCC_LLLL_DDDD is provided for backward compatibility,
     new applications should use _SSSS_IIII_GGGG_CCCC_HHHH_LLLL_DDDD.

     The disposition of signals that are inherited as _SSSS_IIII_GGGG______IIII_GGGG_NNNN should not be
     changed.

     A call to _s_i_g_n_a_l cancels a pending signal _s_i_g except for a pending
     _SSSS_IIII_GGGG_KKKK_IIII_LLLL_LLLL signal.

     A call to _s_i_g_s_e_t with a signal handler other than _SSSS_IIII_GGGG______IIII_GGGG_NNNN will
     automatically allow pending signals for the set signal to come in.

SSSSEEEEEEEE AAAALLLLSSSSOOOO
     _eeee_xxxx_iiii_tttt(2), _gggg_eeee_tttt_rrrr_llll_iiii_mmmm_iiii_tttt(2), _iiii_nnnn_tttt_rrrr_oooo(2), _kkkk_iiii_llll_llll(2), _pppp_aaaa_uuuu_ssss_eeee(2), _pppp_tttt_hhhh_rrrr_eeee_aaaa_dddd______kkkk_iiii_llll_llll(3P),
     _pppp_tttt_hhhh_rrrr_eeee_aaaa_dddd______ssss_iiii_gggg_mmmm_aaaa_ssss_kkkk(3P), _ssss_iiii_gggg_aaaa_cccc_tttt_iiii_oooo_nnnn(2), _ssss_iiii_gggg_aaaa_llll_tttt_ssss_tttt_aaaa_cccc_kkkk(2), _ssss_iiii_gggg_nnnn_aaaa_llll(2), _ssss_iiii_gggg_ssss_eeee_tttt(2),
     _ssss_iiii_gggg_nnnn_aaaa_llll(3B), _ssss_iiii_gggg_pppp_rrrr_oooo_cccc_mmmm_aaaa_ssss_kkkk(2), _ssss_iiii_gggg_ssss_eeee_nnnn_dddd(2), _ssss_iiii_gggg_qqqq_uuuu_eeee_uuuu_eeee(3), _ssss_iiii_gggg_ssss_uuuu_ssss_pppp_eeee_nnnn_dddd(2),
     _wwww_aaaa_iiii_tttt(2), _ssss_iiii_gggg_ssss_eeee_tttt_oooo_pppp_ssss(3C), _ssss_iiii_gggg_iiii_nnnn_ffff_oooo(5), _uuuu_cccc_oooo_nnnn_tttt_eeee_xxxx_tttt(5)










                                                                        PPPPaaaaggggeeee 6666